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Abstract 

Command  and  Control  (C2)  communication  in  a  network  centric  environment  such  as  the 
Global  Information  Grid  (GIG)  is  postulated  to  be  data  “rich”.  However,  our  current 
situation  is  that  the  most  critical  C2  information,  the  commander’s  intent,  orders  and 
directives,  does  not  actually  flow  as  data.  It  is  often  communicated  as  “free  text”.  While 
suitable  for  interpersonal  communication,  it  is  not  able  to  support  advanced  automation 
or  intelligent  decision  aids  due  to  its  inherent  ambiguity.  Battle  Management  Language 
(BML)  was  developed  as  a  solution  to  this  problem. 

BML  is  defined  as  the  unambiguous  language  used  to:  1)  command  and  control  forces 
and  equipment  conducting  military  operations  and,  2)  provide  for  situational  awareness 
and  a  shared,  common  operational  picture.  It  can  be  seen  as  a  representation  of  a 
digitized  commander’s  intent  to  be  used  for  real  troops,  for  simulated  troops,  and  for 
future  robotic  forces. 

Based  on  this  concept,  a  prototype  of  BML  was  developed  demonstrating  an  actual 
National  Training  Center  (NTC)  Brigade  Operations  Order.  The  United  States  (U.S.) 
Defense  Modeling  and  Simulation  Office’s  (DMSO)  Extensible  Modeling  and 
Simulation  (M&S)  Framework  (XMSF)  initiative  is  extending  BML  based  on  open, 
commercial  Internet  standards.  The  XMSF  prototype  demonstrates  a  web-enabled 
Extensible  Battle  Management  Language  (XBML). 


Introduction 


Recent  expert  evaluations  have  demonstrated  that  the  way  that  the  U.S.  Army  performs 
C2  is  primarily  by  a  loosely  knit  “language”  tailored  to  interpersonal  communication.  Its 
vocabulary  is  found  in  doctrinal  task  lists  and  manuals,  but  it  lacks  clearly  delineated 
rules  governing  its  use  (semantics  and  syntax).  It  is  riddled  with  ambiguity  and 
overlapping  definitions.  As  such,  it  is  incapable  of  transitioning  to  the  full  range  of 
automation  that  the  Department  of  Defense  (DoD)  is  implementing.  It  will  not  support 
either  “digitized”  C2  or  decision  support  based  upon  integrated  modeling  and  simulation. 

One  of  the  most  radical  changes  is  the  data  policy  in  the  GIG.  This  is  based  on  the  U.S. 
DoD  Data  Strategy  that  postulates  all  data,  regardless  of  the  final  consumer,  will  be 
available  to  selected  users  (theoretically  anyone,  anywhere  with  granted  access)  on 
“publish-subscribe,”  “smart-push-pull,”  or  query-response  type  mechanisms.  In  sharp 
contrast  to  current  data  this  “stovepipes”  have  been  established  by  Command,  Control, 
Communications,  Computers,  and  Intelligence  (C4I)  system  design  or  by  doctrine  that 
fails  to  make  data  available  until  after  processing  by  the  appropriate  entity,  often  after  it 
is  tactically  useful  by  another  community. 

Communication  of  C2  in  a  network  centric  environment  must  be  less  interpersonal  and 
more  data  oriented.  The  most  critical  C2  information,  the  commander’s  intent,  orders  and 
directives,  does  not  currently  flow  as  data.  It  is  communicated  as  “free  text”  elements 
within  messages  or  as  stand-alone  fdes.  While  suitable  for  interpersonal  communication, 
it  is  inadequate  for  use  with  simulations,  or  for  the  future  forces  that  have  robotic 
components.  As  commanders  increase  their  demand  to  train  as  they  fight  and  therefore 
use  their  C2  devices  to  control  simulations,  a  solution  for  this  “free  text”  problem  must  be 
found.  Battle  Management  Language  (BML)  was  developed  as  a  solution  to  this 
problem. 

BML  is  defined  as  the  unambiguous  language  used  to:  1)  command  and  control  forces 
and  equipment  conducting  military  operations  and,  2)  provide  for  situational  awareness 
and  a  shared,  common  operational  picture.  It  can  be  seen  as  a  representation  of  a 
digitized  commander’s  intent  to  be  used  for  real  troops,  for  simulated  troops,  and  for 
future  robotic  forces. 

Based  on  this  concept,  a  prototypical  implementation  of  how  to  implement  a  Battle 
Management  Language  was  conducted  and  demonstrated  at  the  end  of  2002  and  in  the 
beginning  of  2003.  While  the  first  prototype  was  U.S.  Army  centric,  an  initiative  was 
taken  under  the  DMSO  XMSF  program  to  transform  the  BML  prototype  into  a  joint  and 
combined  solution  based  on  open  standards.  The  XMSF  initiative  has  started  with  this 
BML  prototype  (consisting  of  a  future  U.S.  Army  C2  System  and  a  U.S.  Army  Entity 
Level  Simulation)  and  has  developed  a  web-enabled  prototype  of  Extensible  Battle 
Management  Language  (XBML).  This  version  will  not  be  limited  to  U.S.  Army 
constraints,  and  will  be  “extended”  by  applying  the  concepts  of  the  XMSF.  The  end  state 
for  XBML  will  be  a  methodology  for  developing  standard  doctrinal  terms  and  allowing 


these  to  be  accessed  as  web  services.  Each  Service  could  have  it’s  own  “BML”  Web 
service,  linked  to  a  Joint  overarching  BML. 


XMSF  is  evaluating  the  applicability  of  a  set  of  web-based,  open  standards,  developed  by 
existing  standards  bodies,  and  methodologies  focusing  on  -  but  not  limited  to  -  web- 
based  distributed  modeling  and  simulation.  Because  it  is  based  on  Web  standards,  it  has 
the  ability  to  provide  simulation  services  to  a  wide  class  of  live  systems.  XMSF  uses 
open  standards  and  open  sources  to  increase  the  efficiency  of  development  and 
applicability  of  simulation  systems.  Many  software  systems  composably  scale  to 
worldwide  scope  by  utilizing  Internet  and  web  technologies.  XMSF,  by  applying  these 
web-based  technologies,  is  an  advance  toward  composable  simulation  systems.  It 
furthermore  bears  the  potential  to  migrate  legacy  and  future  M&S  into  web-centric 
components  to  be  used  in  net-centric  Command,  Control,  Communications,  Computers, 
Intelligence,  Surveillance,  and  Reconnaissance  (C4ISR)  environments,  such  as  the  Global 
Information  Grid  [1,2]. 

The  XBML  approach  is  to  adapt  representations  of  C2  so  that  they  are  directly  derived 
from  doctrine  and  are  expressed  in  a  flexible  syntax.  This  provides  a  means  to  link  the 
BML  (terminology  and  symbology)  directly  to  their  doctrinal  source;  and  it  allows 
operational  forces  to  use  their  C4I  systems  to  1)  interact  with  supporting  simulations  to 
conduct  rigorous,  realistic  training  and  support  mission  rehearsals,  and  2)  in  the  future, 
support  an  expedited  military  decision  making  process. 


Why  BML? 

The  central  hypothesis  of  Network  Centric  Warfare  (NCW)  is  that  a  force  with  these 
capabilities  can  increase  combat  power  by:  better  synchronizing  effects  in  the 
Battlespace,  achieving  greater  speed  of  command,  and  increasing  lethality,  survivability, 
and  responsiveness. 

The  concept  of  Network  Centric  Operations  and  Warfare  (NCOW)  is  a  realization  that 
modem  warfighting  efforts  are  a  synergy  of  C2,  enterprise  business  operations,  both 
hierarchical  and  asymmetric  networking,  and  advanced  cognitive  software  applications. 
They  impact  all  levels  of  military  activity  from  the  tactical  to  the  strategic.  In  order  to 
successfully  conduct  warfare  the  Commander  must  simultaneously  work  in  the  Physical, 
Information,  and  Cognitive  domains  maintaining  optimum  situational  awareness  in  all 
three.  This  is  the  challenge  of  modern  C2  in  general,  and  in  particular  a  challenge  for  the 
support  C4ISR.  The  information  domain  must  bridge  the  gap  between  the  physical  and 
the  cognitive  domain  as  much  as  possible. 


The  means  for  accomplishing  this  in  the  DoD  is  with  the  GIG.  A  globally 
interconnected,  end-to-end  set  of  information  capabilities,  associated  processes,  and 
personnel  for  collecting,  processing,  storing,  disseminating,  and  managing  information  on 
demand  to  Warfighters,  policy  makers,  and  support  personnel. 


The  GIG  is  a  key  enabler  of  NCW  and  is  essential  for  information  and  decision 
superiority.  It  will  enable  C4I  integration  of  joint  forces,  improve  interoperability  of 
systems,  and  increase  optimization  of  bandwidth  capacity  thereby  dramatically  improving 
warfighting  capabilities.  The  GIG  will  enhance  operational  capabilities  while  providing  a 
common  environment  for  conventional  and  nuclear  C2,  combat  support,  combat  service 
support,  intelligence,  and  business  functions.  In  particular,  the  GIG  will  support: 

•  Ability  to  operate  with  reduced  forces  at  high  operational  tempos  where  dynamic 
planning  and  redirection  of  assets  is  the  norm. 

•  Delivery  of  information  concerning  targets,  movement  of  forces,  condition  of 
equipment,  levels  of  supplies,  and  disposition  of  assets  to  joint  commanders,  their 
forces,  and  the  National  Command  Authority  (NCA)  within  specified  time 
frames. 

•  Ability  to  obtain  and  use  combat  and  administrative  support  information  from 
national,  allied,  coalition,  and  other  widely  dispersed  assets. 

•  Collection,  processing,  storage,  distribution,  and  display  of  information 
horizontally  and  vertically  throughout  organizational  structures  across  the 
Battlespace. 

•  Rapid  and  seamless  flow  and  exchange  of  information  around  the  globe,  enabling 
collaborative  mission  planning  and  execution  from  widely  dispersed  locations  and 
at  different  levels  (to  include  strategic,  operational,  tactical,  and  business). 

The  GIG  is  a  system  of  systems  that  provides  a  set  of  value-added  functions  operating  in 
a  global  context  to  provide  processing,  storage,  and  transport  of  information;  human-GIG 
interaction;  network  management;  information  dissemination  management;  and 
information  assurance.  These  functions  are  fully  interrelated,  integrated,  and 
interoperable  with  one  another  in  order  to  achieve  overall  interoperability  across  the  GIG. 
As  a  result,  the  GIG  is  an  information  environment  comprised  of  interoperable  computing 
and  communication  components. 

As  military  organizations  move  toward  operating  in  a  network  centric  environment,  they 
are  relying  more  upon  open  commercial  standards  than  previously.  This  is  mainly  due  to 
the  success  of  the  worldwide  Internet  in  the  past  10  years.  To  the  extent  that  commercial 
standards  can  be  used,  this  is  preferable  to  military  specific  standards.  However,  it  is 
recognized  that  there  are  certain  areas  where  military  specific  standards  must  be 
developed.  One  of  these  is  security.  Another  is  the  representation  of  military  tasks, 
actions  and  missions. 

A  critical  deficiency  in  current  simulation  systems  is  the  lack  of  a  standard  methodology 
for  representing  C2  information.  Many  advanced  simulations  have  excellent 
representations  of  C2  internal  to  their  simulations,  but  do  not  use  this  representation  when 
dealing  with  other  simulations  or  C2  systems  (here  we  define  C2  systems  as  the  range  of 
planning  to  execution  systems  used  in  military  operations).  See  [3,  4]  for  related  work  in 
simulation  C2  formats. 


BML  was  developed  as  a  common  standard  to  represent  military  tasks,  actions  and 
missions,  both  in  simulations  and  C2  systems.  A  proof  of  principle  BML  prototype  was 
developed  in  the  domain  of  ground  forces  (for  a  U.S.  Army  Mechanized  Brigade).  As 
BML  development  continues,  the  issue  of  how  to  address  different  domains  is  a  key 
issue. 

BML  will  allow  a  commander  to  develop  a  plan  and  exchange  data  with  other 
organizations  -  the  commander’s  subordinates,  his  superiors  and  his  equals.  However,  in 
a  joint  environment,  this  will  involve  different  services  exchanging  planning  information 
and  plans  with  each  other.  In  a  coalition  environment,  one  nation  will  exchange  plans 
with  another.  Thus,  BML  needs  to  address  the  following  dimensions: 

1)  Service 

2)  Joint 

3)  Multi-National 

This  is  shown  in  Figure  1.  The  coalition  systems  may  belong  to  different  nations  and  be 
specific  to  particular  services  (e.g.,  ground  or  air).  Typically,  a  federation  of  simulation 
systems  will  be  employed  to  support  the  mission  planning  systems  for  training  or 
operations.  In  addition,  the  systems  involved  can  be  highly  aggregated  (such  as  a  joint 
logistics  system  tracking  movement  of  assets  or  a  large  joint  simulation  system)  or  very 
detailed  (platform  specific  systems). 

The  challenge  for  BML  is  to  provide  a  common  methodology,  a  common  syntax  and 
semantics.  However,  each  nation  and  service  will  have  different  tasks  unique  to  itself, 
and  BML  must  be  flexible  enough  to  accommodate  them. 

Extensible  Battle  Management  Language  builds  on  the  experience  of  the  U.S.  Army 


Figure  1 :  XBML  Coalition  Concept 


proof  of  principle  implementation  by  using  Internet  standards  to  develop  web-enabled 
interfaces.  However,  while  Internet  and  Web  standards  are  a  tremendous  aid  to 
developing  flexible  interfaces  (addressing  BML  methodology  and  syntax),  they  do  not 
address  the  issue  of  common  semantics.  XBML  uses  the  Command  and  Control 
Information  Exchange  Data  Model  (C2IEDM)  in  order  to  establish  a  common 
representation  for  tasks,  actions  and  missions.  XBML  represents  mission  in  terms  of 
Who,  What,  Where,  When,  Why  as  an  organizing  principle 

This  paper  focuses  on  how  to  establish  interoperability  between  distinctly  different 
domains,  building  upon  work  in  progress.  BML  is  described  in  [5,  6]  and  [7]  investigates 
the  scalability  of  BML  to  coalition  operations.  The  U.S.  Army  proof  of  principle  is 
described  [8]  in  detail  and  [9,  10]  present  the  first  phase  of  XBML,  concentrating  on 
applying  commercial  Internet  standards  to  “open  up”  the  specific  interfaces.  In  addition, 
Tolk  in  [11]  explains  how  the  C2IEDM  will  be  used  for  semantic  interoperability  for 
XBML  as  well  as  for  M&S  in  general. 

The  remainder  of  this  paper  will  describe  XMSF,  the  current  status  of  XBML,  the 
applicability  of  XBML  to  coalition  operations  and  future  plans 


XMSF 

XMSF  is  a  set  of  profiles  for  use  of  open  standards,  developed  by  existing  standards 
bodies,  and  methodologies  for  their  application,  to  facilitate  reuse,  composability,  and 
orchestrated  execution  of  distributed  and  heterogeneous  M&S.  Because  it  is  based  on 
Web  standards,  it  has  the  ability  to  provide  simulation  services  to  a  wide  class  of  live 
systems.  XMSF  uses  open  standards  to  increase  the  efficiency  of  development  and 
applicability  of  simulation  systems.  Many  software  systems  that  composably  scale  to 
worldwide  scope  utilize  Internet  and  Web  technologies.  XMSF,  by  applying  these  Web- 
based  technologies,  is  an  advance  toward  composable  simulation  systems  and  is  a  viable 
technical  platform  to  integrate  live  systems,  such  as  C2  systems. 

Software  systems  that  composably  scale  to  worldwide  scope  using  Internet  and  Web 
technologies  are  strong  candidates  for  use  in  composable  simulations.  XMSF  is 
characterized  by  the  application  of  open  standards  and  open  sources  to  increase  the 
efficiency  and  applicability  of  distributed  simulation  systems.  Therefore,  XMSF  is  an 
evolutionary  step  toward  advanced  distributed  simulation  not  necessarily  limited  to 
military  standards.  XMSF  uses  particular  standards  related  to  the  Web,  to  reach  the  next 
level  of  this  domain  of  distributed  computing.  By  embracing  commercial  Web 
technologies  as  a  shared-communications  platform  and  a  ubiquitous-delivery  framework, 
military  M&S  can  fully  leverage  mainstream  practices  for  enterprise-wide  software 
development.  Its  focus  on  open,  Web-based  standards  and  technologies  doesn’t  imply 
that  XMSF  is  limited  to  the  public  Internet;  it  can  just  as  well  operate  on  secure  military 
networks.  Two  of  these  Web-based  standards  play  a  particular  role  in  XBML: 


1)  The  Extensible  Markup  Language  (XML)  is  designed  to  improve  the  functionality 

of  the  Web  by  providing  more  flexible  and  adaptable  information  identification.  It 
is  a  standardized  file  format  on  the  basis  of  the  Standard  Generalized  Markup 
Language  (SGML)  and  became  a  wide  spread  standard  for  Web  applications  within 
the  last  couple  of  months. 

2)  The  Simple  Object  Access  Protocol  (SOAP)  is  a  protocol  for  exchange  of 
information  in  a  decentralized,  distributed  environment.  It  is  an  XML  based 
protocol  to  let  applications  exchange  information  over  the  Hyper  Text  Transfer 
Protocol  (HTTP),  which  is  supported  by  all  Internet  browsers  and  servers. 

Agreeing  on  a  common  tag  set  of  underlying  XML  documents  is  the  first  step  allowing 
unambiguous  information  exchange  on  the  semantic  level  of  interoperability.  This  tag  set 
then  can  be  used  to  define  SOAP  message  content  to  be  exchanged  between  these 
applications  via  the  Internet  or  a  Web-based  military  network  supporting  the  minimal  set 
of  Internet  standards  and  may  later  be  used  for  semantically  meaningful  web  service 
definition.  Although  in  complementing  papers  the  need  for  additional  standards  to  insure 
meaningful  interoperability  is  stressed  [12,  13],  this  level  is  sufficient  for  XBML 
applications  and  the  initialization  of  C4I  systems  by  M&S  applications. 

C2  systems  are  of  particular  interest  in  composable  simulations  because  they  are  the 
windows  through  which  the  warfighters  see  the  world.  There  is  a  growing  requirement  to 
interface  existing  and  emerging  simulations  to  C2  systems.  We  believe  that  ultimately 
the  best  solution  is  to  use  the  same  underlying  Information  Technology  (IT)  infrastructure 
supporting  M&S  and  C2  systems,  facilitating  the  delivery  of  simulation  services  for 
operational  applications  as  required.  To  do  this,  XMSF  must  be  extended  and  integrated 
into  emerging  C2  systems  and  standards.  Using  XMSF  to  integrate  simulations  into  C2 
networks  is  discussed  in  [1,  2], 

Given  that  XMSF  addresses  a  critical  technology  base  for  simulation  composability, 
extending  XMSF  to  address  C2  integration  will  bring  a  crucial  domain  as  part  of  the 
overall  set  of  candidates  for  composition.  To  date,  efforts  to  use  Simulations  with  C2 
systems  have  been  fragmented  and  “stovepiped”.  XMSF  provides  mechanisms  for 
addressing  this  issue  systematically  as  well  as  providing  a  deeper  interoperability. 

Warfighters  deal  directly  with  C2  systems,  but  there  are  many  barriers  to  integrating 
simulations  into  C2  systems.  While  technical  solutions  are  necessary,  experience  has 
proven  that  they  are  not  sufficient  to  solve  integration  and  interoperability  problems.  We 
are  including  C2  in  an  XMSF  Distributed  Testbed  in  order  to  demonstrate  the  potential  of 
XMSF  to  the  C2  community  and  provide  a  basis  for  experimentation.  Experimentation 
will  allow  us  to  consider  the  complex  issues  of  dealing  with  live  systems. 

Once  developed,  this  C2  XMSF  testbed  capability  will  support  both  simulations  and  C2 
systems.  This  will  allow  exploration  of  a  number  of  critical  issues  in  C2/M&S 
interoperability  that  have  not  been  addressed  to  date  -  such  as  time  management  and 
labelling  of  live  vs.  simulated  data  [14] 


While  XMSF  provides  the  means  for  technical  integration  in  form  of  a  C4I  testbed 
applicable  to  C4I  and  M&S  components  based  on  open  and  commercially  supported 
standards,  BML  provides  the  means  for  syntactically  and  semantically  unambiguous 
descriptions  of  C2  information,  both  orders  and  situational  awareness.  While  we  will 
define  BML  more  accurately  in  the  following  sections,  for  now  it  can  be  best  thought  of  as 
the  “digitized  commanders  intent”  to  be  used  in  C2  systems,  as  well  as  in  M&S 
applications,  that  need  to  get  orders  from  a  user. 

The  project  described  in  this  paper,  XBML,  merges  both  concepts.  It  builds  on  the 
technical  flexibility  of  XMSF  to  migrate  the  Army  specific  BML  prototype  into  the 
XMSF  environment.  Additional  components  will  be  integrated  to  broaden  the 
applicability  and  BML  will  be  extended  to  cover  other  services  and  even  to  be  used  in 
combined  application  domains  with  international  partners. 

In  the  next  sections  we  will  deal  with  the  underlying  concepts  in  more  detail  before 
describing  BML,  the  XBML  prototype,  and  the  XBML  representation. 


BML  and  XBML  Concepts 

While  XMSF  ensures  the  integration  and  migration  of  components  on  a  technical  level, 
BML  is  the  foundation  for  a  methodology  for  complete  and  unambiguous  specifications 
of  the  commander’s  intent. 

The  Battle  Management  Language  Concept 

Taking  the  widest  possible  interpretation,  BML  is  defined  [7]  as  follows: 

BML  is  the  unambiguous  language  used  to  command  and  control 
forces  and  equipment  conducting  military  operations  and  to 
provide  for  situational  awareness  and  a  shared,  common 
operational  picture. 


Along  with  this  definition,  there  are  four  principles  that  are  fundamental  to  BML: 

1)  BML  must  be  unambiguous; 

2)  BML  must  not  constrain  the  full  expression  of  a  commander’s  intent; 

3)  BML  must  use  the  existing  C2  data  representations  when  possible;  and 

4)  BML  must  allow  all  elements  to  communicate  information  pertaining  to  themselves, 
their  mission  and  their  environment  in  order  to  create  situational  awareness  and  a 
shared,  common  operational  picture. 


BML  must  contain  no  distinction  between  live  or  simulated  forces,  thus  ensuring  that 
commanders  and  staff  can  train  as  they  fight.  They  will  use  the  same  BML  whether  they 


are  dealing  with  live 
subordinates,  a  simulation,  or  a 
semi-autonomous  robotic  entity 
as  in  Figure  2. 

BML  is  more  than  a  well- 
structured  language.  In  its 
complete  expression,  BML  must 
be  a  methodology  that  allows 
complete  and  unambiguous 
specification  of  C2  information, 
directly  linked  to  doctrine.  The 
methodology  must  represent 
doctrine,  identify  appropriate 
doctrinal  sources,  elaborate 
doctrine  into  a  standardized 
authoritative  representation,  and 
specify  the  rules  for  how  the 
representation  communicates 
information 

To  accomplish  this,  the  BML  must  incorporate  doctrinal  terms,  graphics,  tactics,  etc.  in  a 
form  that  allows  the  intricate  relationships  of  these  abstract  concepts  to  be  linked  to  the 
physical  aspects  of  the  warfighter’s  environment  (organizations,  features,  persons, 
facilities,  and  materiel).  The  representation  must  include  the  necessary  entities  along  with 
well-defined  relationships.  This  then  allows  the  basic  vocabulary,  semantics  and  syntax 
to  be  unambiguously  defined  as  well  as  related  to  each  other  in  a  methodology.  This 
implies  developing  structured  message  formats  that  can  be  parsed  into  existing  and  future 
operational  messages  as  well  as  formats  that  communicate  with  simulations. 

BML  must  blend  structure  that  allows  automation  of  the  language  with  ease  of  use  for  the 
military  professional.  It  should  not  be  a  radical  change  from  the  language  the  commander 
and  staff  currently  use,  but  instead  an  evolution  that  provides  a  means  to  gain  structure 
while  remaining  transparent  to  the  user.  It  must  be  based  on  doctrine  and  linked  to  the 
doctrinal  sources,  both  to  ensure  standard  use/understanding,  and  to  foster  concise  and 
precise  use  of  the  language.  The  technology  components  of  BML  must  support  the  “train 
as  you  fight”  concept  and  therefore  exist  in  a  single  format,  at  least  as  far  as  the  military 
professional  user  is  concerned.  The  output  of  the  automated  system  is  dependent  on 
whether  the  intended  audience  is  a  human,  a  software  “intelligent  agent”  or  an 
autonomous  robot. 

BML  is  being  built  based  upon  work  that  has  gone  before  -  EAGLE  [3]  (a  U.S.  Army 
constructive  force-on-force  simulation)  BML,  the  Command  and  Control  Simulation 
Interface  Language  (CCSIL)  [4],  and  as  a  Task  Decomposition  Methodology  [15]. 
Recently,  an  assessment  [16]  of  the  BML  Prototype  was  performed  providing  a  useful  set 
of  evaluation  criteria. 


Figure  2:  BML  Scope 
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Figure  3:  BML  Concept 


Figure  3  shows  graphically  our  BML  implementation  concept.  This  consists  of: 

•  A  C2  Database  (used  by  a  C2  application).  BML  must  be  imbedded  and  integrated 
into  the  C2  Database. 

•  A  Doctrine  Repository,  with  doctrine  accessible  to  the  C2  application.  The  more 
strongly  the  BML  terms  are  tied  to  how  live  forces  are  trained  and  employed  will 
enable  how  well  BML  will  perform. 

•  A  technology  to  disseminate  BML  terms  from  the  Doctrine  Repository  and  a 
technology  for  exchanging  BML  messages. 

Figure  4  shows  the  scope  of  the  BML  methodology.  This  paper  shows  how  BML  can  be 
extended  from  a  service  specific  implementation  (Army  using  specific  interfaces)  to  an 
approach  linking  coalition,  joint  and  service  elements.  It  is  important  to  note  that  there 
may  be  different  BML  “dialects”.  A  populated  BML  for  the  Army  will  be  different  from 
a  populated  BML  for  the  Air  Force  due  to  the  difference  in  how  they  employ  their  forces. 
But  the  way  that  a  BML  language  is  constructed  must  be  standard  so  BML  information 
can  be  exchanged  and  understood. 

A  key  aspect  of  BML  is  that  with  the  vocabulary  and  its  associated  relationships  built 
into  a  database,  Graphical  User  Interfaces  (GUI)  and  other  applications  can  be 
constructed  that  allow  implementation  of  BML. 

The  development  of  XBML  is  being  conducted  in  phases.  As  the  XMSF  project  looked 
at  BML,  it  was  fairly  straightforward  to  determine  which  XMSF  standards  would  be 
applied  first,  in  order  to  “open  up”  the  interfaces.  Follow-on  phases  include  migrating  to 
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Figure  4:  BML  Methodology 

the  C2IEDM,  integrating  additional  components,  and  extending  the  semantics  of  the 
BML  vocabulary. 


Development  of  XBML 

In  this  section  we  describe  what  was  done  in  Phase  1  of  XBML,  conducted  in  2003. 

The  U.S.  Army  BML  proof  of  principle  comprises  the  following  elements  as  shown  in 

Ligure  5: 

•  To  generate  orders,  the  Combined  Arms  Planning  and  Execution  System 
(CAPES)  is  used.  This  is  a  prototype  U.S.  Army  Planning  System.  This  C2 
component  creates  operational  orders  (OpOrds)  that  are  exchanged  using  a 
proprietary  tagged  XML  document. 

•  A  Multi  Source  Data  Base  (MSDB)  is  based  on  the  U.S.  Army  Standard  data 
model  of  the  Joint  Common  Data  Base  (JCDB),  which  has  been  extended  by  the 
BML  development  team  by  introducing  over  100  new  tables  and  relations.  It  is 
accessed  via  standardized  database  manipulation  statements  based  on  Open  Data 
Base  Connectivity  (ODBC)  or  Java  Data  Base  Connectivity  (JDBC).  It  is 
implemented  in  open  source  software  of  the  Linux  environment. 

•  A  BML  Demonstrator  specific  XML-BML  Parser  reads  the  information  from  the 
XML  document  and  generates  data  manipulation  statements.  The  XML-BML 
Parser  reads  the  XML  document,  maps  the  information  to  data  elements  of  the 
MSDB,  and  inserts  the  information  contained  in  the  document  into  the  MSDB. 

•  A  BML  Graphical  User  Interface  (BML-GUI)  allows  data  manipulation  of  the 
content  of  the  MSDB  under  consideration  of  the  semantic  and  syntactic 
constraints  of  the  BML.  The  input  of  CAPES  can  be  used  as  a  basis  to  create 
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Figure  5:  Army  BML  Proof  of  Principle 

more  detailed  operational  orders  for  the  subordinated  units  (which  are  simulated 
using  the  OTB  simulation  system).  The  paradigm  here  is  who-what-when-where- 
why,  also  called  “the  5Ws.” 

•  The  MSDB  information  is  based  on  the  U.S.  Army  doctrinal  language.  In  order  to 
execute  such  orders,  this  information  has  to  be  mapped  from  doctrinal  terms  to 
OTB  interpretable  terms.  This  is  done  by  the  C4I  Simulation  Interface  (C4ISI), 
which  reads  the  MSDB  and  generates  order  files  for  OTB. 

•  Finally,  the  M&S  component  OneSAF  Testbed  Baseline  (OTB)  system  is  used 
to  simulate  the  effect  of  the  generated  orders.  It  reads  the  order  generated  by 
C4ISI  and  executes  them  respectively. 

Figure  5  shows  a  simplified  version  of  the  U.S.  Army  BML  Proof  of  Principle  (PoP) 
demonstration.  Note  that  each  element  of  the  PoP  communicates  with  the  MSDB  in  a 
different  manner,  using  unique  interfaces  and  protocols.  Also  the  components  must  be 
physically  resident  on  a  local  network.  The  BML  PoP  is  more  fully  described  in  [8] 

It  is  worth  mentioning  that  the  Army  BML  prototype  focused  on  the  C2  application.  Its 
objective  was  to  proof  that  an  unambiguous  definition  based  on  Army  doctrine  is  possible 
(by  defining  the  BML  vocabulary),  that  C2  data  can  be  used  as  a  hub  (by  extending  the 
JCDB),  and  that  an  application  can  support  C4I  as  well  as  M&S  components  (by 
coupling  with  CAPES  and  OTB). 

Figure  6  shows  the  results  of  the  first  phase  of  XBML.  Each  of  the  interfaces  between 
the  components  comprising  the  original  Army  BML  PoP  demonstration  environment 
were  investigated  to  determine  approaches  to  incorporate  open,  Web-based  methods  to 
implement  the  interfaces  to  conform  with  the  principles  of  XMSF.  As  indicated  earlier, 
two  Web-based  standards  that  were  chosen  to  implement  the  interfaces  to  construct  the 
XBML  prototype  were  XML  and  SOAP.  XML  was  used  to  provide  a  standard  way  to 
structure  the  data  passed  between  the  components.  SOAP  was  used  to  package  the  ODBC 
and  JDBC  calls  to  the  MSDB  database.  More  details  on  this  are  given  in  [9,  10] 
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Figure  6:  XBML  Testbed  -  Distributed  Interfaces 


XBML  Extensions 

This  section  will  address  how  BML  can  be  extended  to  coalition  members  through  use  of 
the  C2IEDM  data  structures.  The  foundation  for  this  was  developed  in  [17,  18,  19,  20], 

Development  of  C2IEDM  for  Coalition  Interoperability 

When  examining  interoperability  issues  concerning  the  different  Services,  or  between 
nations  in  a  coalition,  we  usually  consider  coordination  issues  (e.g.  how  they  work 
together).  We  are  not  immediately  concerned  with  if  their  C2  systems  are  interoperable 
with  simulations.  Since  the  early  1990’s  the  U.  S.  Services  have  undertaken  an  extensive 
revision  of  Service  and  Joint  doctrine  to  1)  document  their  doctrine;  and  2)  standardize 
and  align  their  doctrine.  Both  activities  had  the  goal  of  improving  interoperability  in 
training  and  execution.  This  same  process  is  occurring  within  formal  alliances  such  as 
the  North  Atlantic  Treaty  Organization  (NATO). 

It  is  almost  impossible  to  imagine  a  situation  in  the  future  when  a  single  U.  S.  Service 
will  be  unilaterally  employed.  Because  future  military  operations,  and  a  significant 
amount  of  training,  will  be  Joint  in  nature,  it  is  critical  that  a  Joint  Service  approach  be 
taken  to  the  BML  development  effort.  The  same  issues  that  have  driven  the  Army  to 
embark  on  this  program  also  confront  the  other  Services  as  they  develop  both  their  C2 
and  simulation  systems. 
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Figure  7:  Subset  of  C2IEDM  Tables  showing  the  5  Ws 

A  BML,  as  described  in  this  paper,  developed  and  applied  by  the  other  Services  and  by 
Coalition  members  would  not  only  allow  interoperability  among  their  C2  systems  and 
simulations,  but  also  among  themselves. 

Just  as  the  BML  PoP  implemented  the  5Ws  within  the  JCDB,  Figure  7  shows  similar 
structures  within  the  C2IEDM.  We  believe  that  the  same  concept  for  developing  BML  for 
the  U.  S.  Army  will  also  work  for  the  other  Services,  Joint  and  Combined/Coalition 
operations  (see  Figure  4)  [6,  21], 


Brief  History  of  C2IEDM 

To  motivate  why  C2IEDM  is  our  model  of  choice  to  represent  BML  and  BML 
extensions,  a  short  history  should  be  given.  More  details  concerning  the  data  semantics 
of  the  C2IEDM  are  given  in  [11].  In  1978,  NATO’s  Long-Term  Defense  Plan  (LTDP) 
Task  Force  on  C2  recommended  that  an  analysis  be  undertaken  to  determine  if  the  future 
tactical  Automatic  Data  Processing  (ADP)  requirements  of  the  Nations  (including  that  of 
interoperability)  could  be  obtained  at  a  significantly  reduced  cost  when  compared  with 
previous  approaches.  In  early  1980,  the  then  Deputy  Supreme  Allied  Commander 
Europe  initiated  a  study  to  investigate  the  possibilities  of  implementing  the  Task  Force’s 
recommendations.  This  resulted  in  the  establishment  of  the  Army  Tactical  Command 


and  Control  Information  System  (ATCCIS)  Permanent  Working  Group  (APWG),  to  deal 
with  the  challenge  of  the  future  C4I  systems  of  NATO.  The  technical  feasibility  was 
demonstrated  several  times  and  ATCCIS  based  systems  were  demonstrated  at  the  annual 
Joint  Warrior  Interoperability  Demonstrator  (JWID)  programs.  Finally,  the  ATCCIS  data 
model  became  a  NATO  standard  (Allied  Data  Publication  Number  32  -  ADatP-32)  with 
the  new  name  Land  Command  and  Control  Information  Exchange  Data  Model 
(LC2IEDM)  adapted  in  1999. 

In  parallel  to  this,  the  Multilateral  Interoperability  Program  (MIP)  was  established  by  the 
project  managers  of  the  Army  Command  and  Control  Information  Systems  (C2IS)  of 
Canada,  France,  Germany,  Italy,  the  United  Kingdom  and  the  United  States  of  America 
in  April  1998  in  Calgary,  Canada.  MIP  replaced  and  enhanced  two  previous  programs: 
BIP  (Battlefield  Interoperability  Program)  and  QIP  (Quadrilateral  Interoperability 
Program). 

By  2002,  the  activities  of  ATCCIS/LC2IEDM  and  MIP  were  very  close,  expertise  was 
shared,  and  specifications  and  technology  were  very  similar.  The  merger  of  ATCCIS  and 
MIP  was  a  natural  and  positive  step  and  this  was  recognized  by  the  almost  immediate 
publication  of  a  NATO  policy  that  endorses  MIP.  LC2IEDM  became  the  data  model  of 
MIP,  which  established  the  Message  Exchange  Mechanism  (MEM)  and  the  Data 
Exchange  Mechanism  (DEM)  based  on  replication  mechanism.  In  2003,  the  name  was 
changed  to  C2IEDM. 

In  summary,  C2IEDM  is  a  mature  model  applicable  to  data  management  as  well  as  to 
information  exchange  and  has  been  successfully  applied  in  the  international  context 
within  NATO. 


XBML  Extensions  to  C2IEDM 

C2IEDM  comprises  a  lot  of  information  necessary  to  model  the  various  XBML 
requirements.  However,  the  new  application  domains  are  likely  to  contribute  domain 
specific  extensions  which  have  to  be  captured  by  C2IEDM.  To  this  end,  the  rules 
established  by  NATO  will  be  applied.  Figure  8  exemplifies  how  XBML  will  extend  the 
basic  C2IEDM  structures  with  specific  Service  mission  information.  As  with  current 
coalition  exercises  using  the  C2IEDM,  different  nations  and  services  will  have  to  agree 
upon  the  extension  to  be  used  for  a  particular  exercise  or  operation. 

The  key  principles  of  C2IEDM  extensions  are  that: 

.  The  basic  C2IEDM  data  representations  are  not  changed,  and 
.  Extensions  are  always  done  in  the  least  obtrusive  manner,  i.e.,  (a)  new  information 
is  modelled  by  new  attribute  values  first.  If  this  is  not  sufficient,  (b)  the  category 
and  subcategory  codes  are  extended  in  order  to  generate  new  subtypes  of  existing 
concepts.  If,  and  only  if  this  is  not  sufficient,  (c)  new  concepts  and  associations 
are  introduced. 


The  applicability  of  these  rules  in  the  domains  of  BML  is  a  current  area  that  the  XBML 
testbed  is  exploring. 

It  is  apparent  that  as  XBML  grows,  a  method  must  be  set  up  to  “manage”  the  extensions 
used.  Furthermore,  the  results  have  to  be  fed  back  to  the  C2IEDM  community  in  order  to 
have  a  controlled  growth  of  the  standard.  Managing  data  within  the  C2IEDM  is 
discussed  extensively  in  [1 1], 


Conclusion 

The  C2  community  is  shifting  from  the  system  centric  view  to  the  net  centric  view. 
While  until  recently  this  was  mainly  limited  to  the  conceptual  preparation  of  the 
transformation  of  the  armed  forces,  the  advent  of  the  GIG  and  GIG  Enterprise  Services  is 
now  enabling  the  technical  implementation  of  the  underlying  ideas.  Net  Centric  Warfare 
[22]  is  finally  becoming  a  reality.  Joint  Command  and  Control  (JC2)  is  on  its  eve  of 
implementation.  Operational  M&S  functionality  is  technically  ready  to  be  integrated  and 
operationally  required  to  support  modem  military  operations.  We  have  presented  a  case 
for  XBML  as  a  necessary  standardization  effort  to  harmonize  M&S  standards  with  GIG 
requirements. 

In  summary,  XMSF  is  a  broad  integration  method  based  on  open  standards.  BML  is  a 
collection  of  methods  to  capture  C2  information  in  an  unambiguous  way.  XBML  is 
merges  these  two  concepts  in  a  powerful  manner. 

There  is  a  need  for  a  unified  BML  methodology.  BML  is  vital  to  achieve  C2  to 
Simulation  interoperability.  It  can  also  assist  in  achieving  C2  interoperability  within  Joint 
and  coalition  environments  acting  as  the  true  common  language  between  humans, 
machines,  Services  and  National  militaries. 


Figure  8:  Notional  BML  Extensions  to  the  C2IEDM  5W  Core 


With  XBML  we  have  demonstrated  the  capability  of  distributed,  remote  operation  of 
web-enabled  components.  The  concept  of  simulation  applications  implemented  as  Web 
services  will  support  future  network  centric  operational  concepts.  The  Web  based 
implementation  facilitates  the  ‘smart-pull’  concept  of  information  distribution  as 
described  in  the  DoD  Net-Centric  Data  Strategy. 
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BML  as  an  Enabler  for  Network  E 
Centric  Operations 
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S  Amplify  capability  of  manned 
elements 

S  Multi-functional  (RSTA,  armed, 
sustainment) 

Increased  Reliance  on  Extended 

Range  Engagement 

S  Organic  plus  strategic  and  tactical 
support 

S  Long  range  ISR  and  precision  fires 

Capable  of  Air-Mobile  Operations 

S  Commercial  and  minimum  DoD 
strategic  and  tactical  lift 


Organic  & 
Inorganic 
RSTA 


Direct  Fire 
Function 


Indirect  Fire 
Function 


Infantry  Carrier  +  C2 
Function 


2004  CCRTS,  15-17  June  2004,  San  Diego,  CA 


The  Problem 


Current  and  emerging  simulations  do  not  have 
the  capability  of  directly  interacting  with  C4I 
systems. 

-  They  require  the  development  of  unique  interfaces  (“black 
boxes”)  for  each  pairing  of  a  simulation  and  a  C4I  system 

-  They  require  significant  non-training  audience  intervention  in 
order  to  support  digital  battle  staff  training  and  they  will  continue 
to  do  so  until  a  standardized  Battle  Management  Language  is 
developed  for  communicating  between  these  systems. 

-  The  most  difficult  aspect  of  this  problem  is  in  communicating 
mission  type  orders  from  the  command  nodes  to  the  supporting 
simulations.  Generically  this  is  known  as  the  “Free  Text 
Problem.” 
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Current  Situation 


E 


•  Our  current  “BML”  is  a  loosely  knit  “language”  tailored  to 
interpersonal  communication. 

•  Its  vocabulary  is  found  in  Doctrinal  Manuals,  but  it  lacks  clearly 
delineated  rules  governing  its  use  (semantics  and  syntax). 

•  It  is  riddled  with  ambiguity  and  overlapping  definitions. 

•  As  such,  it  is  incapable  of  transitioning  to  the  full  range  of 
automation  that  the  DoD  is  implementing. 

•  It  will  not  support  the  integration  of  advanced  modeling  and 
simulation  with  “digitized”  command  and  control. 
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What  Is  Battle  Management 
Language  (BML)? 


E 


•  BML  is  the  unambiguous  language 
used  to: 

-  Command  and  control  forces  and 
equipment  conducting  military 
operations,  and 


-To  provide  for  situational  awareness 
and  a  shared,  common  operational 
picture. 
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Principles  of  BML 


El 


BML  must  be  unambiguous 


BML  must  not  constrain  the  expression  of  a 
commander’s  intent 


BML  must  use  standardized  data 
representations 


BML  must  allow  forces  to  communicate 
information  pertaining  to  their  mission,  their 
status  and  their  environment 
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BML  Scope 
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BML  Views 


Representation 
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Course  of  Action  Analysis  Example  RSSSw 

Graphics  convert  to  BML 
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Paragraph  1 :  Enemy  Most  Probable  CoA 
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Extensible  Modeling  and 
Simulation  Framework 

•  What  is  XMSF? 


-  The  Extensible  Modeling  and  Simulation  Framework  (XMSF)  is  defined 
as  a  set  of  Web-based  technologies  and  services,  applied  within  an 
extensible  framework,  that  enables  a  new  generation  of  modeling  & 
simulation  (M&S)  applications  to  emerge,  develop  and  interoperate. 


•  XMSF  Precepts 

-  Web-based  technologies  can  provide  an  extensible  modeling  and 
simulation  architecture,  to  support  a  new  generation  of  interoperable 
applications 

-  Simulation  support  is  needed  for  operational  warfighting  capabilities 

-  XML-based  architecture  can  provide  a  bridge  between  emerging 
rehearsal/reality/replay  requirements  and  open/commercial  Web 
standards 

-  Web  =  best  tech  strategy  +  best  business  case 
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What  Is  XBML? 


XBML  is  BML  provided  as  a  Web  Service 

XBML  is  being  developed  as  an  integral 
part  of  the  Extensible  Modeling  and 
Simulation  Framework 
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Applying  XMSF  Principles  to  BML 


•  BML  must  utilize  Web  Standards  for  Message  Transmission 

•  SOAP 

•  XML 

•  BML  must  use  a  standard  “vocabulary” 

•  the  Command  and  Control  Information  Exchange  Data  Model 
(C2IEDM) 

•  This  results  in: 

•  Distributed,  Flexible  Interfaces 

•  Common  Syntax  and  Semantics  between  Services,  and 
Coalition  Partners 

•  Unambiguous  terms  needed  for  Simulation  Execution 
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Why  use  the  C2IEDM  for  XBML? 


•  History  of  C2IEDM 

•  Developed  by  NATO  data  modeling  experts  (ATCCIS  Permanent 
Working  Group) 

•  Based  on  the  Information  Exchange  Requirements  on  the 
Battlefield 

•  Unambiguous  Representation  of  Information 

Extensible  Data  Model 

•  NATO  Standard  ADatP-32 

•  Use  by  the  NATO  Data  Administration  Group 

•  Core  Data  Model  for  various  C4I  Systems 

•  Reference  Data  Model  for  various  Simulation  Systems 

•  Data  Model  for  Multilateral  Interoperability  Program  (MIP) 
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ACTION-OBJECTIVE 


ACTION-id  (FK) 
ACTION-OBJECTIVE-index 


ACTION-OBJECTIVE-categoiy-  vi/tta/ 
code  WHY 


ORGANISATION-TYPE 

ORGANISATION-TYPE-id 


ORGANISATION-TYPE  -category-code 


ORGANISATION-TYPE- 

CATEGORY-CODE 


UNIT-TYPE 

POST-TYPE 


UNIT-TYPE 


UNIT-TYPE-id  (FK) 


UNIT-TYPE  -category-code 
UNIT-TYPE  -mobility-code 
UNIT-TYPE  -service-code 
UNIT-TYPE  -size-code 

(echelon) 


5  Ws  in  C2IEDM 


ORGANIZATION-POINT  FEATURE-LOCATION 


LOCATION  WHERE  -- 

/ 

.  _/ 
i 

\ 

LOCATION-id 

\  FACILITY-LOCATION 

PERSON-POINT 

LOCATION  -categoiy-code 

\ 

\ 

N 

N 

X 
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Joint  BML  Implementation  Concept:  ^",S!P 

Extend  the  C2IEDM 
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Extending  the  BML  Vocabulary  to  ESMSS# 

Air  Operations 

Begin  with  Air  C2DIF  (Command  and  Control  Data 
Interchange  Format) 

-  Developed  by  Gestalt  -  AF/ESC  Sponsorship  (1998) 

-  Vetted  in  over  120  Exercises/Events/Demonstrations/Tests 

Includes  the  Following  Categories 

-  Air  Battle  Plan 

•  Air  Tasking  Order  (ATO) 

•  Airspace  Control  Order  (ACO) 

•  Special  Instructions  (SPINS) 

•  Mission  Feedback 

•  Friendly  Order  of  Battle  (FRoB) 

•  Scenario  Data  (UOB) 

-  Mission  Representation 

•  Includes  More  Detailed  Mission  Planning  Aspects  of  ATO  Directed 
Missions 

•  Supports  the  “Decrease  of  the  Controller  Footprint  Goal” 
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XBML  Coalition  Concept 
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Conclusions 


BML  can  provide  a  true  common  language  between 
humans,  machines,  Services  and  national  militaries 

-  Will  enable  command  and  control  interoperability  within 
Joint  and  coalition  environments 

The  concept  of  simulation  applications  implemented 
as  Web  services  will  support  future  network  centric 
operational  concepts 

We  have  demonstrated  the  capability  of  distributed, 
remote  operation  of  web-enabled  components 
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